Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General refactoring #11

Merged
merged 211 commits into from
Jan 12, 2023
Merged

General refactoring #11

merged 211 commits into from
Jan 12, 2023

Conversation

FotiosBistas
Copy link
Contributor

@FotiosBistas FotiosBistas commented Aug 3, 2022

Motivation

Needed functionality for the command line interface especially to implement the transferring of CIDs from Optimistic Provide to the CID hoarder.

Description

The CID hoarder can generate/publish content from different types of sources. These sources can be a file containing CIDs, random generation of the content and receiving the cids from bitswap protocol.

Tasks

  • Implement a basic interface to determine the source of the CIDs and the corresponding content (already implemented but can refactor if new source is needed)

  • Implement generating random CIDs (Already implemented by @cortze )

  • Implement the reading from JSON file functionality

  • Implement asynchronous way to add provider records into the hoarder that are published by other sources.

  • Implement reading from text file functionality

  • Implement not publishing the CIDs and pinging existing ones in the network. (the most important for the transferring of the CIDs)

  • Implement the reading from bitswap functionality

cortze and others added 7 commits July 4, 2022 19:24
Update Analyzer + Improve tool with extra Ping round Info
Changed the name of the file to CID-gen.go to cid_source.go. The command line will be able to take CIDs from a file and publish them to the network.
Options in creating a new config struct
Moved CidSource interface to cid_source file.
Added a file cid source
Added a bitswap cid source.
Created function find_cid_source which figures out what type of cid will be used.
Copy link
Owner

@cortze cortze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @FotiosBistas ! Great work! I think that you are on track!
Just left a few comments. Let me know what you think!

pkg/config/config.go Outdated Show resolved Hide resolved
pkg/config/config.go Outdated Show resolved Hide resolved
pkg/hoarder/hoarder.go Outdated Show resolved Hide resolved
struct FileCIDSource now contains the file, the filename and the scanner used to read the file.
The idea is that the GetNewCid() function will use the current state of the scanner to read the next CID along with it's contents.
I have doubts about using the parse function here to convert the string read from the file to a CID
Added error handling to the read file method.
@@ -67,9 +71,31 @@ func (bitswap_cid_source *BitswapCIDSource) Type() string {
return "bitswap"
}

func read_content_from_file() ([]byte, cid.Cid, error) {
//Reads CID and content from a given file. Starting idea for the file format should be CID CONTENT([]byte array)\n.
func read_content_from_file(conf *config.Config) ([]byte, cid.Cid, error) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you could leave the content aside, it's probably a random one. Furthermore, it isn't relevant for the Cid-Hoarder to know the exact bytes of a given CID.
It would also simplify the step for exporting/importing the CIDs

Copy link
Contributor Author

@FotiosBistas FotiosBistas Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I leave out the content I would need to change the interface type:

type CidSource interface {
	GetNewCid() ([]byte, cid.Cid, error)
	Type() string
}

Every time a GetNewCid() is called it returns the CID , it's content and an nil error if all went well. In the latest commit which handles errors it's more clear how I thought about it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, although it is never used.
You can return an empty []byte and it won't crash, it will also save you some time parsing the file with the CIDs.
Might happen that you want to track a CID from where you don't know the content yet

Copy link
Contributor Author

@FotiosBistas FotiosBistas Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay makes sense. What do you think would be best to change the interface or just return a nil type in the place of []byte when reading from a file?
The usage of []byte is here:

// TODO: is it worth keeping the content?
// getRandomContent returns generates an array of random bytes with the given size and the composed CID of the content
func genRandomContent(byteLen int) ([]byte, cid.Cid, error) {
	// generate random bytes
	content := make([]byte, byteLen)
	rand.Read(content)

	//TODO do we have to have different CID types?
	// configure the type of CID that we want
	pref := cid.Prefix{
		Version:  1,
		Codec:    cid.Raw,
		MhType:   mh.SHA2_256,
		MhLength: -1,
	}

	// get the CID of the content we just generated
	contID, err := pref.Sum(content)
	if err != nil {
		return content, cid.Cid{}, errors.Wrap(err, "composing CID")
	}

	log.Infof("generated new CID %s", contID.Hash().B58String())
	return content, contID, nil
}

Yeah I saw that //TODO now.

Copy link
Owner

@cortze cortze Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think would be best to change the interface or just return a nil type in the place of []byte when reading from a file?

mmmm, I would just return an empty []byte for now, it might be useful in the future

@cortze cortze merged commit bda5745 into cortze:dev Jan 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants